Various embodiments of the present invention relate to the field of computer programming.
Many modern programming languages provide facilities for dynamic allocation of memory for objects or other data structure instances created by applications at run-time. Some languages such as C and C++ require explicit user action for reclaiming such dynamically allocated memory, while other languages such as Java and C# provide support for memory management that enables automatic reclamation of dynamically allocated memory. For example, the Java programming language allocates objects within the Java Virtual Machine (JVM) heap. When an object is no longer required, it is not explicitly released or removed from the heap. In order to remove unused objects, Java provides a built in capability for the collection of unreferenced dynamically allocated objects, herein referred to as xe2x80x9cgarbage.xe2x80x9d The automatic memory management capability is commonly referred to as xe2x80x9cgarbage collectionxe2x80x9d.
Garbage collection provides the ability to release and reclaim memory when it is no longer required, thus providing a paradigm that enables the creation of more efficient applications. However, garbage collection itself adds a performance overhead to many Java applications. In particular, Java enterprise applications that utilize significant system memory resources can be performance or capacity impaired based on the garbage collection activity that they produce as the workload they are processing increases. This leads to slow and sometimes unreliable operation of Java enterprise applications.
Except for the situations where garbage collection overhead is a direct result of software defects, non-optimal heap memory usage and incorrect policy choices for the garbage collector are the primary causes of increased garbage collection overhead. The process of configuring the heap for optimal memory usage and fine-tuning the garbage collector policies is referred to as xe2x80x9cgarbage collector tuning.xe2x80x9d
Garbage collector tuning can yield a very large performance payoff (e.g., 100 percent, or even substantially higher) on certain enterprise applications by optimizing the heap memory usage and reducing the total time spent in garbage collection. This enables one to achieve predictable and optimal performance of applications, written in Java or similar programming languages.
Current garbage collection tools are integrated as part of Java profiling or monitoring solutions. These tools typically rely on measuring heap capacity using either published Java interfaces, or rely on the garbage collection trace option available in an implementation of the JVM. While these tools provide a user with some guidance for optimizing garbage collection, these tools have a number of drawbacks. Most significantly, these tools do not provide any guidance on the actual optimal garbage collection parameters, and provide no relief from the expensive process described below.
FIG. 1 is a flowchart diagram illustrating a process 100 for garbage collection tuning in accordance with the prior art. At step 105, the memory allocation behavior trace used to configure the garbage collection is specified to the interpreter. At step 110, an application is executed for the programming language which the application was written in. At step 115, the trace data is analyzed. At step 120, it is determined whether or not the desired results were achieved. If so, process 100 ends. Alternatively, if desired results were not achieved, as shown at step 125, the heap parameters are adjusted based on the analysis and process 100 returns to step 105.
Typically, garbage collection is subject to user-entered or default parameters. In order to determine which parameters to insert, a user must run the application and analyze the results of the Java heap behavior. For example, a user must perform a run of the application to allow for collection of heap behavior data, and analyze the results. While the overall garbage collection time may be small, garbage collections may take a substantial amount of the overall execution time for large applications, such as enterprise applications. For example, the garbage collection on a large application dominate the overall execution time. Upon completing a run of the application, the heap behavior data is analyzed and the new parameters are specified by the user based on this analysis. This process is repeated until the desirable parameters are entered.
Furthermore, in order to optimize garbage collection, a user must determine new parameters whenever the application is changed or whenever the platform is changed. The time spent running the application, collecting the heap behavior data, and analyzing the results can be sizable, resulting in substantial costs to those running the applications.
Additional problems arise when the application being analyzed is being diagnosed off-site. It is typically too cumbersome to install an application, particularly on a third party computer system. Furthermore, the owner of the application may not want to install the application on a third party computer system due to privacy concerns. As such, a third party must tell the user which parameters to enter, then wait until the application is run, and the heap behavior data is collected. This consumes the computing resources of the application owner, and may impose extra costs beyond those associated directly with running the application (e.g., network downtime and lowered performance of other applications).
A method for optimization of memory usage for a computer program is presented. Memory usage data is received wherein the memory usage data comprises timing information. A graphical representation of the memory usage data is generated. At least one heap parameter is received. A memory usage simulation is performed based on the memory usage data and the heap parameter.